1. Field of the Invention
The present invention relates to a communications system, and more particularly to a symmetric bus bridge whose primary and secondary interfaces are separated and in which the role of the primary and secondary interface can be switched under software/application control (thereby providing the symmetry).
2. Description of the Related Art
FIG. 1 illustrates a generic bus architecture for a conventional system. That is, FIG. 1 shows a system 100 with a typical bus bridge.
System 100 includes a controller 101 (e.g., CPU), a primary bus 102 connecting the controller to one or more devices 103 (e.g., D1, D2, etc.), a bus bridge 104 connecting the primary bus to a secondary bus 105 and one or more devices 106 (e.g., D3, D4, D5, etc. which may be similar or different from those of devices 103) connected to the secondary bus 105.
During system configuration, the bus bridge 104 is responsible for storing and forwarding configuration information from the controller 101 to devices 106 connected to the secondary bus 105. The bus bridge 104 has an interface B0 to the primary bus 102 and an interface B1 to the secondary bus 105.
The configuration process includes bus numbering, device discovery, and resource allocation (e.g., memory space, IO space, interrupts, etc.) to each of the devices 106 as per device request. After configuration is complete, devices 106 connected to the secondary bus 105 (e.g., behind the bus bridge), appear in the memory map and/or IO map of the controller 101 in the same way as devices 103 connected to the primary bus 102.
The bridge 104 stores all the pertinent information in its internal configuration register space, which is accessed by the controller 101 during the configuration process. The information stored in the configuration registers is also used regularly at runtime by the bus bridge 104 to decide when to claim transactions originating at one bus and forward it to the other bus. It is noted that only the primary bus interface is allowed to read from/write to the configuration register space of the bus bridge.
In a typical communications environment (e.g., a single bus), a device wishing to communicate by either reading data from or writing data to another device on the bus 102 generally performs the following steps.
That is, for Dx (e.g., one of D1, D2, etc.) reads from Dy (another of devices D1, D2, etc.), first Dx arbitrates for bus ownership.
When granted, Dx takes control of the bus and asserts the address of the destination device (Dy) as well as the transaction type it wishes to perform (e.g., read). The transaction may also need to be qualified by other parameters (e.g., memory versus input/output (I/O) read, (starting) address read transaction, single read versus burst mode read, and the number of data elements to read in case of a burst read mode).
All other devices decode the information asserted by the originating device Dx. The addressed device, Dy, responds by acknowledging the transaction.
When Dx sees the acknowledge, it has to relinquish control of the data portion of the bus to enable the target device, Dy, to transmit the requested data. The mechanism of turning the direction of data flow over the bus is implementation specific and may vary from one architecture to another.
Thereafter, Dy transmits the required data element(s) over the bus. Dy could optionally stall the bus until it is ready to transmit the data.
When the required data element(s) is(are) transmitted over the bus, both Dx and Dy relinquish the bus so that it is ready for a new transaction.
For Dx writing to Dy, first Dx arbitrates for bus ownership.
When granted, Dx takes control of the bus and asserts the address of the destination device (Dy) as well as the transaction type it wishes to perform (write). The transaction also may need to be qualified by other parameters (e.g., memory versus I/O write, (starting) address write transaction, (starting) data element, single write versus burst mode write, and the number of data elements to write in case of a burst write mode).
All other devices decode the information asserted by the originating device Dx. The addressed device, Dy, responds by acknowledging the transaction.
When Dx sees the acknowledge, it transmits the desired data element(s) to Dy. Dy could optionally stall the bus until it is ready to receive the data.
When the required data element(s) is (are) transmitted over the bus, Dx releases the bus such that it is ready for a new transaction.
However, as shown in FIG. 1, communications can be performed across a so-called xe2x80x9cbus bridgexe2x80x9d 104. That is, two busses 102, 105 can be linked together using the bus bridge 104. Devices connect to different busses can communicate with each other through the bus bridge. For the purposes of the following discussion, it is assumed that Dx resides at Bus 102 and Dy at Bus 105.
In contrast to the operations discussed above, for Dx reads from Dy, first Dx arbitrates for Bus 102 ownership.
When granted, Dx takes control of the bus and asserts the address of the destination device (Dy) as well as the transaction type it wishes to perform (e.g., read). The transaction may also need to be qualified by other parameters (e.g. memory versus I/O read, (starting) address. read transaction, single versus burst mode read, and the number of data elements to read in case of a burst read mode).
All other devices decode the information asserted by the originating device Dx. Since Dy resides on Bus 105, B0 responds on behalf of Dy by acknowledging the transaction.
When Dx sees the acknowledge, it has to relinquish control of the data portion of the bus to enable the target device, B0, to transmit the requested data. The mechanism of turning the direction of data flow over the bus is implementation specific and may vary from one architecture to another.
B0 stalls Bus 102 until it fetches the requested data from Dy across the bridge.
While stalling Bus 102, B0 transmits a request packet across its communications link to the receiving bridge connected to Bus 105, namely B1.
Upon receiving the request, B1 will read the requested data from Dy. This is achieved by following the steps of xe2x80x9cDx reads from Dyxe2x80x9d scenario described above in the above-described first case, but replacing Dx by B1.
When the read transaction on Bus B is completed, B1 will packetize the data and transmit back across the communications link to B0.
Then, B0 starts transmitting the data to Dx. When the required data element(s) is(are) transmitted over the bus, both Dx and B0 relinquish Bus 102 so that it is ready for a new transaction.
Regarding Dx writes to Dy, first Dx arbitrates for Bus 102 ownership.
When granted, Dx takes control of the bus and asserts the address of the destination device (Dy) as well as the transaction type it wishes to perform (e.g., write). The transaction may also need to be qualified by other parameters (e.g., memory versus IO write, (starting) address write transaction, (starting) data element, single versus burst mode write, and the number of data elements to write in case of a burst write mode).
All other devices on Bus 102 decode the information asserted by the originating device Dx. Since Dy resides on Bus B, B0 responds on behalf of Dy by acknowledging the transaction.
When Dx sees the acknowledge, it transmits the desired data element(s) to B0. B0 accepts the data, then stalls the bus until it has completed the transaction on the remote side (i.e., Bus 105). Alternatively, B0 might release the bus, but not respond to any more transactions until it has completed the current transaction on the remote side.
B0 transmits a data packet across its communications link to the receiving bridge connected to Bus 105, namely B1.
Upon receiving the data packet, B1 will write the data to Dy. This is achieved by following the steps of xe2x80x9cDx writes to Dyxe2x80x9d scenario described above in the above-described first case, but replacing Dx by B1.
When the write transaction on Bus 105 is completed, B1 will transmit an acknowledge packet back across the communications link to B0 to signal the completion of the transaction of bus 105.
B0 now releases the stalled bus, possibly giving a positive acknowledge to Dx to inform it that the transaction has successfully completed. (Alternatively, B0 will now start accepting new transactions destined to devices across the bridge). Then, Dx releases Bus 102 so that it is ready for a new transaction.
However, the conventional system of FIG. 1 is deficient since it has a fixed architecture in defining the primary bus interface and the secondary bus interface. Thus, it is impossible to switch the roles of the primary and secondary interfaces after system design, and thus the flow of control across the bridge, with respect to system configuration, is fixed.
In view of the foregoing problems, drawbacks, and disadvantages of the conventional systems, it is an object of the present invention to provide a structure (and method) in which the roles of primary and secondary bus interfaces can be switched selectively.
In a first aspect, in a system that includes a controller, a plurality of busses coupled to the controller, a plurality of devices coupled to the busses, and at least one bus bridge coupling at least two busses of the plurality of busses, wherein the bus bridge includes at least two interfaces each providing an interface to a different one of the two busses coupled thereto, and wherein the controller executes a configuration routine to configure the system, a method for initializing the bus bridge includes providing memory storing configuration information used in conjunction with the configuration routine, selecting an arbitrary one of the two interfaces of the bus bridge based upon a control signal, and enabling access to the memory by the selected one of the interfaces of the bus bridge for use in conjunction with the configuration routine, and disabling access to the memory by the other one of the interfaces of the bus bridge.
In a second aspect, a communications system (and method therefor) includes first and second controllers communicatively coupled together, a plurality of busses respectively coupled to the controllers, a plurality of devices coupled to the busses, and at least one bus bridge coupling at least two busses of the plurality of busses.
In a third aspect, a method of resolving conflict between first and second busses of a plurality of busses in a communication system, includes establishing initial communication between the first and second busses, exchanging configuration information between the first and second busses, comparing a local side configuration to a remote side configuration, and determining whether the local side configuration is identical to the remote side configuration, and if so then raising a conflict flag to resolve the conflict.
Further, a signal-bearing medium (e.g., program storage device) is provided for storing the method(s) of the invention.
Thus, with the unique and unobvious features of the invention, a bus bridge is provided in which the role of the primary and secondary interface can be switched under software/application control (thereby providing the symmetry).
Further, the invention allows two computer systems, each with its own controller (CPU) and peripheral devices to be coupled through the symmetric bus bridge, one computer system on each side of the bridge, such that any controller (CPU) can become the xe2x80x9cmasterxe2x80x9d of the combined system taking over the peripheral devices originally associated with the other computer system across the symmetric bridge, mapping them to its own memory or IO space while the other computer system""s controller (CPU) is disabled. Furthermore, the role of the master controller (CPU) can be switched on a session-by-session basis (hence the symmetry).